From: Mary Boetcher, mary_boetcher@quickmail.apple.com
Reply-To: ODF Interest, ODF-Interest@CILabs.ORG
To: OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
Mail*Link® SMTP RE>RE>Linking & ODF Draw
Scott,
When ODFDraw externalizes its part content in CDrawPartContent::Externalize, it writes:
1) each shape in the shape list (CDrawContent::ExternalizeShapeList)
2) each link object (FW_CLinkManager::ExternalizeLinks)
3) part settings (CDrawPart::ExternalizeAnnotations)
When the shapes are written out in (1), they're assigned indices from 1..n. An index is just a tag to identify a particular shape, since you can't use ptrs inside a storage unit.
When the Link Manager externalizes the part's links in (2), it iterates over its lists of Link objects and calls ExternalizeLink for each one. The part's Link classes must override DoExternalizeLink in order to write out part-specific data. This data is used when the part is internalized, to re-create the link objects.
ODFDraw's Link classes (CDrawPublishLink and CDrawSubscribeLink) keep track of what shapes are linked by means of content objects (CDrawLinkSourceContent* fPublishedContent and CDrawLinkContent* fLinkedContent, respectively). Each CDrawXxxContent object contains a shapeList inherited from the base class. When a CDrawPublish/SubscribeLink is externalized, we don't want to write out all of its linked shapes too, because they have already been written out by ExternalizeShapeList. Instead we simply iterate over the linked shapes and write out their indices.
When the part is internalized, first the part's shapes are read in and instantiated. Next the part's links are read, along with the shape indices. After a link object has been instantiated, it uses the indices to find the corresponding shapes and add them to its link content (see CDrawLinkManager::DoInternalizeOneSourceLink). Once the shapes have been added to the link content's shapeList, the indices are no longer needed.
>>Could you please explain or
>>point me to some documentation that would elaborate on exactly what I
>>am supposed to do to support linking?
The ODF Developer's Guide explains what you need to subclass and override to support Linking in your part.
>>You admitted there may be a bug in ODF Draw in this area.
I looked at it some more, and now I think there is no problem. ODFDraw's CDrawSelectionContent::Internalize currently does not internalize links. If this is added in the future we'll have to be careful about how the shape indices are handled.
>>I am writing graphical shapes somewhat like Draw, but in the
>>part content, they are not stored sequentially, but they are stored
>>sequentially in the selection content. So, I can number them in the
>>selection or link content (and even the part content I suppose), but
>>I need to know how and when to do this.
You need to identify each shape uniquely - the numbers do not have to be sequential. Perhaps you could use a shape's pointer as an unsigned long value.
